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PREFACE 


This  systea  administrator's  guide  covers  the  work  performed 
under  Air  Foroe  Contract  F33615-80-C-5155  (ICAM  Project  6201). 
This  contract  is  sponsored  by  the  Materials  Laboratory,  Air 
Force  Systeas  Coaaand,  Wright-Pat ter son  Air  Force  Base,  Ohio . 

It  was  adainistered  under  the  technical  direction  of  Mr.  Gerald 
C.  Shuaaker.  ICAM  Prograa  Manager,  Manufacturing  Technology 
Division,  through  Project  Manager,  Mr.  David  Judson.  The  Priae 
Contractor  was  Production  Resources  Consulting  of  the  General 
Electric  Coapany,  Schenectady,  Hew  Tork,  under  the  direction  of 
Mr.  Alan  Rubenstein.  The  General  Electric  Project  Manager  was 
Mr.  Myron  Hurl but  of  Industrial  Autoaation  Systeas  Departaent, 
Albany,  Hew  Tork. 

Certain  work  ained  at  iaproving  Test  Bed  Technology  has 
been  perforaed  by  other  contracts  with  Project  6201  perforaing 
integrating  functions.  This  work  consisted  of  enhancements  to 
Test  Bed  software  and  establishment  and  operation  of  Test  Bed 
hardware  and  conauni oat ions  for  developers  and  other  users. 
Documentation  relating  to  the  Test  Bed  froa  all  of  these 
contractors  and  projeots  have  been  integrated  under  Project  6201 
for  publication  and  treatment  as  an  integrated  set  of  documents. 
The  particular  contributors  to  each  document  are  noted  on  the 
Report  Documentation  Page  (DD1473).  A  listing  apd  description 
of  the  entire  project  documentation  systea  and  hoVv^hey  are 
related  is  contained  in  doouaent  FTR6201 00001 ,  Project  Overview. 

The  subcontractors  and  their  contributing  activities  were 
as  follows: 


TASK  4.2 

Subcontractors 

Boeing  Military  Aircraft 
Company  (BMAC) 

D.  Appleton  Coapany 
(DACOM) 


General  Dynaaios/ 
Ft.  Worth 


Role 

Reviewer. 


Responsible  for  IDEF  support, 
state-of-the-art  literature 
searoh . 

Responsible  for  factory  view 
function  and  information 
models . 
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Subcontractors 

Illinois  Institute  of 
Technology 

North  American  Rockwell 
Northrop  Corporation 

Pritsker  and  Associates 
SofTech 


Role 

Responsible  for  factory  view 
funotion  research  (IITRI) 
and  information  models  of 
small  and  medium-sine  business. 

Reviewer. 

Responsible  for  factory  view 
function  and  information 
models. 

Responsible  for  IDKF2  support. 
Responsible  for  ID8F0  support. 


TASKS  4. 5  -  4.9  (TEST  BED) 


Subcontractors 


Role 


Boeing  Military  Aircraft 
Company  (BMAC) 


Responsible  for  consultation  on 
applications  of  the  technology 
and  on  IBM  computer  technology. 


Computer  Technology 
Associates  (CTA) 


Assisted  in  the  areas  of 
communications  systems,  system 
design  and  integration 
methodology,  and  design  of  the 
Network  Transaction  Manager. 


Control  Data  Corporation 
(GDC) 


Responsible  for  the  Common  Data 
Model  (CDM)  implementation  and 
part  of  the  CDM  design  (shared 
with  DAOOM) . 


D.  Appleton  Company 
(DAOOM) 


Responsible  for  the  overall  CDM 
Subsystem  design  integration 
and  test  plan,  as  well  as  part 
of  the  design  of  the  CDM 
(shared  with  CDC).  DAOOM  also 
developed  the  Integration 
Methodology  and  did  the  schema 
mappings  for  the  Application 
Subsystems . 
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Subcontractors 


Role 


Digital  Equipment 
Corporation  (DEC) 


McDonnell  Douglas 
Automation  Company 
(McAuto) 


On-Line  Software 
International  (OSI) 


Consulting  and  support  of  the 
performance  testing  and  on  DEC 
software  and  computer  systems 
operation. 

Responsible  for  the  support  and 
enhancements  to  the  Network 
Transaction  Manager  Subsystem 
during  1984/1985  period. 

Responsible  for  programming  the 
Communications  Subsystem  on  the 
IBM  and  for  consulting  on  the 
IBM. 


Rath  and  strong  Systems 
Products  (RSSP)  (In  1988 
became  McCormack  9  Dodge) 


Sof Tech .  Inc . 


Software  Performance 
Engineering  (SPE) 


Structural  Dynamics 
Research  Corporation 
(SDRC) 


Responsible  for  assistance  in 
the  implementation  and  use  of 
the  MRP  II  package  (PIOS)  that 
they  supplied. 

Responsible  for  the  design  and 
implementation  of  the  Network 
Transaction  Manager  (NTM)  in 
1981/1984  period. 

Responsible  for  directing  the 
work  on  performance  evaluation 
and  analysis. 

Responsible  for  the  User 
Interface  and  Virtual  Terminal 
Interface  Subsystems. 


Other  prime  contractors  under  other  projects  who  have 
contributed  to  Test  Bed  Technology,  their  contributing 
activities  and  responsible  projects  are  as  follows: 


Contractors 


I CAM  Project  Contributing  Activities 


Boeing  Military 
Aircraft  Company 
(BMAC) 


1701,  2201,  Enhancements  for  IBM 
2202  node  use.  Technology 

Transfer  to  Integrated 
Sheet  Metal  Center 

(ISMC). 
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Contractors 

ICAM  Project 

Contributing  Activities 

Control  Data 
Corporation  (CDC) 

1502,  1701 

IXSS  enhancements  to 
Common  Data  Model 
Processor  (COMP). 

D.  Appleton  Company 
(DAOOM) 

1502 

IISS  enhancements  to 
Integration  Methodology. 

General  Electric 

1502 

Operation  of  the  Test 
Bed  and  communications 
equipment. 

Huglies  Aircraft 

Company  (HAC) 

1701 

Test  Bed  enhancements. 

Structural  Dynamics 
Research  Corporation 
(SDRC) 

1502,  1701, 
1703 

IISS  enhancements  to 
User  Interface/ Virtual 
Terminal  Interface 
(UI/VTI). 

Systran 

1502 

Test  Bed  enhancements. 
Operation  of  Test  Bed. 

vi 
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SECTION  1 

ADMINISTRATOR'S  GUIDE 


There  are  many  functions  performed  by  the  Test  Bed  System 
Adminstrator .  These  functions  include  creating  new  user 
accounts ,  assigning  privileges  and  quotas,  tape  processing 
procedures,  backup  procedures,  and  ORACLE  database  procedures. 
These  will  be  discussed  in  the  following  sections. 

1 .  Adding  New  Accounts 

There  are  four  basic  types  of  accounts  that  can  be  set 
up  on  the  test  bed.  They  are  IISS  development  and 
integration,  individual  development,  interested 
observers,  and  general  access.  When  creating  new 
accounts,  it  is  necessary  to  evaluate  the  request  and 
determine  into  which  category  the  account  will  fall. 

A)  IISS  development  and  integration  account  is  used  by 
authorized  members  within  a  sub-contractor  group. 
Current  IISS  subsystem  development  and  integration 
with  other  subsystems  is  done  here.  Files  such  as 
data,  command,  and  form  files  will  reside  in  this 
account.  Only  executables  for  the  particular 
development  subsystem  will  reside  here;  all  other 
executables  for  the  other  subsystems  reside  in  the 
production  IISS  (PUSS)  area  and  IISS  will  point  to 
them  in  that  location. 

1)  Privileges  and  quotas  -  This  type  of  account 
requires  the  privileges  TMPMBX,  NETMBX,  and 
GRPNAM.  The  approximate  disk  quota  required 
for  file  storage  and  IISS  development  is  50.000 
blocks.  The  following  are  quotas  which  should 
be  set  when  the  account  is  created: 


PRIO:  4 
PRCLM:  32 
ASTLM:  10 
ENQLM:  300 
TQELM:  30 
MAX JOBS:  0 


BYTLM:  99000 
PBYTLM:  0 
VSDEFAULT:  200 
WSQU0TA:  768 
WSEXTENT :  2048 
MAXACCT JOBS :  0 


BIOLM:  12 
DIOLM:  12 
FILLM:  120 
SKRFILLM:  0 
CPU:  NO  LIMIT 
PGFLQUOTA:  50000 


2)  Unless  specifically  requested,  these  accounts 
do  not  require  VPS-PLUS,  word  processing. 
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privileges. 

3)  Unless  specifically  requested,  these  accounts 
do  not  require  Documentation  Management 
privileges. 

4)  Because  of  the  development  status  of  these 
accounts,  they  should  be  set  up  with 
Configuration  Management  privileges.  Many  CM 
activities  will  take  place  directly  from  this 
account,  such  a6  checking  out  and  returning 

f i les . 

MOTE:  Because  of  Group  assignments  and  mailbox 
handling,  it  is  recommended  that  only  one  IISS 
development/ integration  account  be  created 
within  a  group. 

B)  Individual  development  accounts  are  used  by 

individuals  contributing  to  the  subsystem  for  which 
their  sub-contractor  group  is  responsible.  Source 
and  link  files,  as  well  as  other  development  files 
may  be  located  here.  However,  any  files  developed 
in  this  account  should  by  moved  to  the  main 
integration  test  area  for  the  sub-system  for 
thorough  testing. 

1)  Privileges  and  quotas  -  This  type  of  account 

requires  the  privileges  TMPMBX  and  NETMBX.  The 
approximate  disk  quota  required  for  this  type 
of  account  is  10000  blocks.  Additional  disk 
quota  may  be  required  in  this  type  of  account, 
based  on  the  level  of  activity  taking  place 
here.  The  following  are  quotas  which  should  be 
set  when  the  account  is  created: 


PRIO:  4 

BYTLM:  8192 

BIOLM:  6 

PRCLM:  10 

PBYTLM:  0 

DIOLM:  6 

ASTLM:  10 

WSDEFAULT:  200 

FILLM:  30 

ENQLM:  200 

WSQUOTA:  768 

SHRFILLM:  0 

TQELM:  10 

VSEXTEHT:  2048 

CPU:  MO  IjIMIT 

MAX JOBS:  0 

MAXACCTJOBS :  0 

PGFLQUOTA:  10000 

2)  Unless 

specifically  requested. 

these  accounts 

do  not 

require  WPS-PLUS,  word 

processing. 

privileges . 
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S)  Unless  specif ically  requested,  these  accounts 
do  not  require  Documentation  Management 
privileges. 

4)  Because  of  the  development  status  of  these 
accounts,  they  should  be  set  up  with 
Configuration  Management  privileges.  CM 
activities  will  take  place  directly  from  this 
account,  such  as  checking  out  and  returning 
files. 

C)  Interested  observers  are  accounts  for  individuals 
who  wish  to  be  kept  informed  of  activities  on  the 
test  bed.  For  the  most  part,  activity  in  these 
accounts  is  limited  to  receiving  and  sending 
messages  via  the  VAX  MAIL  facility. 

1)  Privileges  and  quotas  -  This  type  of  account 
requires  the  privileges  TMPMBX  and  METMBX.  The 
approximate  disk  quota  required  for  this  type 
of  account  is  10000  blocks.  The  following  are 
quotas  which  should  be  set  when  the  account  is 
created : 


PRIO:  4 
PRCLM:  10 
ASTLM:  10 
ENQLM:  200 
TQELM:  10 
MAX JOBS:  0 


BYTLM:  8192 
PBYTLM:  0 
WSDEFAULT :  200 
WSQUOTA:  768 
WSEXTEHT:  2048 
MAXACCT JOBS :  0 


BIOLM:  6 
DIOLM:  6 
FILLM:  30 
SHRFILLM:  0 
CPU:  MO  LIMIT 
PGFLQUOTA:  10000 


2)  Unless  specifically  requested,  these  accounts 
do  not  require  VPS-PLUS,  word-processing, 
privileges . 

3)  Unless  specifically  requested,  these  aooounts 
do  not  require  Documentation  Management 
privileges. 


4)  Unless  specifically  requested,  these  accounts 
do  not  require  Configuration  Management 
privileges. 


D)  General  aooess  accounts  are  created  for  loading 
software  packages  onto  the  test  bed,  such  as  IDSS 
and  MCMM.  Due  to  the  nature  of  the  account,  it  is 
very  difficult  to  set  standards  for  their  oreation. 
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1)  Privileges  and  quotas  -  Dependent  upon  the 
software  to  he  loaded. 

2)  These  accounts  do  not  require  VPS-PUJ8, 
word-processing,  privileges. 

S)  These  aooounts  do  not  require  Documentation 
Management  privileges. 

4)  These  aooounts  do  not  require  Configuration 
Management  privileges. 

2 .  Tape  Procedures 

A)  Procedures  for  loading  tapes  onto  the  test  bed  have 
been  created.  Below  is  the  fora  which  should  be 
used  when  there  is  a  need  to  load  files  onto  the  AF 
VAX.  Fill  in  all  information  and  submit  the  fora, 
via  mail,  to  the  SYSTEM  account,  the  aooount  used 
for  Operation  requests.  MOTE:  Please  number  the 
tape  and  refer  to  this  tape  number  in  the  fora  when 
notifying  Operations.  Xf  a  corresponding  fora  has 
not  been  received  by  Operations  when  a  tape  is 
reoeived,  the  tape  will  not  be  loaded. 

The  following  is  an  explanation  of  the  input  necessary  on  the 
fora: 

(1)  Enter  the  tape  number  which  corresponds  to  the 
actual  number  on  the  tape  sent  to  Operations. 

(2)  Enter  date  of  request  for  tape  load. 

(3)  Enter  name  of  sub-contracting  company  making 
request . 

(4)  Enter  name  of  person  making  request. 

(5)  Enter  telephone  number  of  requestor. 

(6)  Enter  the  name  of  the  aooount  on  the  AF  VAX 
whioh  is  to  reoeive  the  files  from  the  tape, 
including  disk  name  (e.g.  XISS_DVLP: [GARVJ  ). 

(7)  Enter  the  full  command  used  to  oreate  this 
tape. 

(8)  Enter  the  total  amount  of  disk  spaoe  required 
to  load  tape. 

MOTE:  Be  sure  aooount  has  sufficient  disk  quota 
available  before  this  request  is  made. 
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TAPE  IHFORMATIOH  REQUIRED  FOR  DO  AD I KG 
A  TAPE  OK  THE  AF  VAX 


REQUEST: 


(l)TAPE  HUMBER: _  (2)DATE  OP  REQUEST 

(S)SUBOOKTRACTOR: _  (4)KAME  OP  REQUESTOR: 

(5) PB0KE  HUMBER: _ 

(6) FULL  KANE  OP  RECEIVIXG  AOOOUKT: _ 

(7) SPECIFIC  OOMMAKD  USED  TO  CREATE  TAPE: _ 

(8) DISK  SPACE  REQUIRED  TO  LOAD  TAPE: _ 

(9) TAPE  IKPORMATIOH: 

(a) DEHSITY : _ 

(b) IP  COPY  -  TAPE  LABEL: _ 

IP  BACKUP  -  SAVESET  HAMS: _ 

IP  OTHER  -  METHOD  USED: _ 

BLOCKS I ZE: _ 

RECORD  LEXGTH: _ 

BLOCKIHG  FACTOR: _ 

CHARACTER  MODE: _ 

( 10)  AOOOUKT  OH  AF  VAX  TO  BE  MOTIF I ED: _ 

C 1 1 )DISPOSITIOM  OP  TAPE: _ 

MOTES: 


RESPOHSE : 


DATE/TIME  COMPLETED:  BY: 

HUMBER  OP  PILES: _  HUMBER  OF  BLOCKS: 

MOTIFIED  REQUESTOR-TIME/DATE: _ 

MOTES: 
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(9)  Enter  the  density  of  the  tape  (e.g.  1600  bpi ) . 
If  the  tape  was  oreated  using  COPY,  then  enter 
the  tape  label.  If  the  tape  was  created  using 
BACKUP,  then  enter  the  saveset  nano.  If  the 
tape  was  oreated  using  sone  other  net hod,  enter 

e  Method  used 
e  Blocksise 
e  Reoord  length 
e  Blocking  factor 
e  Character  node  (EBCDIC/ ASCI I) 

(10)  Enter  the  usernane  of  the  account  which  should 
be  notified  upon  oonpletion  of  this  request. 

(11)  Enter  your  choice  for  disposition  of  tape 
[e.g.,  return  to  requestor  (please  list 
address),  scratch  tape,  store  in  tape  archives 
until  specific  date  (please  give  date)). 

B)  To  have  a  tape  nade  of  infornation  on  the  test  bed. 

send  a  nessage .  via  VAX  MAIL,  to  the  SYSTEM  account 

with  the  following  infornation: 

1)  List  specifio  files  to  be  copied  to  tape, 
including  the  drive,  directory,  subdirectory, 
and  file  naaes. 

2)  Specify  preference  for  procedure  to  be  used  to 
create  the  tape:  BACKUP  or  COPY  (default  is 
BACKUP). 

5)  Unless  otherwise  specified,  a  1600  lq>i  tape 
will  be  oreated. 

4)  Specify  naae  and  nailing  address  where  tape 

should  be  shipped.  Be  sure  to  speoify  a  street 
address  since  overnight  oarriers  will  not 
deliver  to  a  post  offioe  box. 

S .  Backup  Procedures 

In  order  to  insure  that  all  aspeots  of  IISS  can  be 
recreated  in  the  event  of  equipnent  failure,  several 
backup  procedures  have  been  developed  on  the  testbed. 
These  procedures  will  copy  files  to  tapes  or  disks, 
which  are  then  6tored  appropriately  at  on  and  off-site 
locations . 

A)  The  daily  increnental  backup  to  tape  (BACKUP.COM) 

is  perforned  every  norning  to  capture  all  file 
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activity  for  the  preceding  day.  A  series  of  two 
weeks  of  these  daily  incrementals  is  kept  in  the 
tape  archives.  The  system  is  available  to  all 
users  during  this  backup  procedure. 

B)  The  weekly  image  backup  to  disk  is  performed 
Thursday  nights  and  takes  5-6  hours  to  complete. 

The  procedure  is  to  be  run  with  no  other  users  on 
the  system,  thus  capturing  all  files  and  insuring 
file  integrity.  All  five  disks  are  backed-up  to 
disks  mounted  on  DRA1 . 

C)  The  weekly  incremental  backup  to  tape  is  run  Friday 
evening.  Duration  i6  determined  by  file  activity 
during  the  previous  week.  This  procedure  captures 
all  file  activity  for  the  preceding  week.  The 
system  is  available  to  all  users  during  this  backup 
procedure . 

D)  The  Configuration  Management  accounts  are  backed-up 
to  tape  on  a  weekly  basis.  The  accounts  SUSS, 
CKDB,  and  MUSS  contain  all  of  the  source  code 
necessary  to  rebuild  IISS  or  reoreate  old  IISS 
releases.  A  full  backup  of  files  in  these  accounts 
is  put  to  tape,  a  log  is  created,  and  the  log  is 
sent  to  the  system  administrator  for  verification 
of  successful  completion. 

4.  General  Access  Areas 

The  system  access  areas,  as  previously  mentioned, 
contain  products  which  have  been  loaded  onto  the  test 
bed.  This  software  is  available  for  general  use  by  all 
users  of  the  system.  Protections  are  set  so  all  of  the 
necessary  executables,  data,  and  symbols  are  available 
to  all  test  bed  users.  The  aocess  areas  include  MCMM, 
IDSS,  and  PP0CS. 

5.  ORACLE  Database  Administration 

There  are  currently  two  versions  of  ORACLE  on  the  test 
bed  computer.  ORACLE  version  3.0.12  is  installed 
system-wide.  This  installation  was  used  for  IISS 
Release  1.8  and  previous  versions.  ORACLE  version 
4.2.2  is  installed  group-wide  and  has  been  used  for 
IISS  Release  2.0,  the  ourrent  release. 
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A)  For  ORACLE  installation' procedures,  refer  to  the 
ORACLE  Systen  Administrators  Guide. 

B)  Multiple  Environment  -  Since  there  are  many 
devlopment  areas  for  IISS,  there  should  also  he 
multiple  database  environments.  Raoh  IISS 
development /integration  account  should  have  an 
associated  database  environment  to  insure  data 
integrity.  Starting  with  IISS  Release  2.0,  all  of 
the  database  environments  exist  under  one  group 
(063).  Individual  databases  should  be  created 
(refer  to  the  ORACLE  System  Administrators  Manual), 
initialised  and  have  data  imported  or  entered  in 
some  manner.  For  subsequent  IISS  releases,  it  is 
the  responsibility  of  the  database  administrator 
for  the  related  IISS  development  area  to  keep  the 
database  current. 

C)  User  Aocess  -  Several  group-wide  logical s  must  be 
defined  by  the  IISS  development/integration 
account .  Mote  that  the  assignment  of  these  group 
logical s  should  never  be  made  from  the  ORACLE 
database  environment  account.  This  will  effeot  all 
database  users  in  such  a  way  that  will  cause  all 
database  activity  to  access  and  update  the  database 
environment  specified  in  the  group  logical . 

7.  Files 

All  aooounts  are  created  with  the  following  feature: 
only  five  versions  of  any  file  will  exist  at  a  given 
time.  This  means  that  when  the  sixth  version  of  a  file 
is  created,  the  earliest  version  of  that  file  will 
automatically  be  deleted.  All  ourrent  users  are  aware 
of  this  feature. 

8.  Helpful  Hints  For  IISS 

Then  IISS  developers  report  strange  results,  check  the 
following  items  for  possible  solutions. 

A)  Verify  that  the  user  is  running  from  an  authorised 
IISS  development/ integration  account . 

B)  Verify  that  the  user  has  sufficient  disk  quota.  To 
run  IISS,  the  user  will  need  at  least  12-15,000 
blocks  of  disk  quota  unused  on  thier  account. 
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C)  Verify  that  the  database  that  the  user  is 
attempting  to  aooess  has  been  wara-started  and  is 
running.  By  entering  SHOW  SYSTEM,  the  version  of 
ORACLE  should  have  four  ORACLE!  prooesses  running. 
Check  logical s  to  be  oertain  they  are  pointing  to 
the  database  environment  that  they  should  be 
accessing. 

D)  To  run  the  User  Interface,  verify  that  a  file  naaed 
(.;)  exists  containing  only  a  oarriage  return. 

E)  Verify  that  all  logical s  are  pointing  to  the 
correct  sub-direotory  for  the  necessary 
executables,  foras,  etc.  Verify  that  the  oorreot 
disk  naae  is  also  specified. 
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